AWS ParallelCluster 既存クラスターの設定を変更する手順 – fish シェル編

AWS ParallelCluster 既存クラスターの設定を変更する手順 – fish シェル編

私が「本当に必要だったもの」はfishユーザーがコピペ済むチートシートです。
#HPC
#AWS ParallelCluster 3
#AWS
#fish
大村 保貴

大村 保貴

facebook logohatena logotwitter logo
Clock Icon2024.02.11

AWS ParallelCluster で作成済みのクラスターに対して、クラスターのコンフィグを変更して設定反映させるための作業手順を紹介します。

以前 bash 向けの手順を作成したものを fish ユーザー向けにブラッシュアップしました。

既存クラスターの設定反映手順まとめ

変更対象の既存のクラスター名を確認します。

pcluster list-clusters | jq -r '.clusters[] | [.clusterName,.version,.region] | @tsv'

確認したクラスター名と、設定変更したコンフィグファイルを変数に入れます。

set CLUSTER_NAME [Target Cluster name]
set CONFIG_NAME [Your config file]

コンピュートフリートを停止します。STOPPEDの表示を確認できれば正常です。

pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status STOP_REQUESTED
while true
    pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
    sleep 3
end

既存クラスターへ設定を反映する前にドライランを実行してコンフィグをチェックします。Request would have succeeded, but DryRun flag is set.確認できれば正常です。

pcluster update-cluster --cluster-name $CLUSTER_NAME \
                        --cluster-configuration $CONFIG_NAME \
                        --dryrun true

既存クラスターに設定を反映させます。UPDATE_COMPLETEの表示を確認できれば正常です。

pcluster update-cluster --cluster-name $CLUSTER_NAME \
                        --cluster-configuration $CONFIG_NAME
while true
    pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .clusterStatus
    sleep 3
end

コンピュートフリートを開始します。RUNNINGの表示を確認できれば正常です。

pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status START_REQUESTED
while true
    pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
    sleep 3
end

以上で作業完了です。

実際に試したときの作業記録

実際に既存クラスターの設定を変更したときのコマンドの実行ログを参考までに紹介します。

実行環境

pclsuterコマンドの実行環境は Docker コンテナで用意したものを利用しています。

変更内容

コンピュートノードのパーティションqueue1の最大起動ノード数を 20 台から 50 台へ変更します。

    # ------ Compute 1 ------
    - Name: queue1
      ComputeResources:
        - Name: queue1
          Instances:
            - InstanceType: m7i.8xlarge
            - InstanceType: m7a.4xlarge
          MinCount: 0
          MaxCount: 50

重要なこと

既存クラスターの設定値は変更可能なものと、変更不可なものがあります。また変更可能あっても変更には条件があるものもあります。事前に対象の設定綱目のUpdate policyを確認しましょう。

今回変更するMaxCountはコンピュートフリートが停止状態であれば変更可能と記載があります。

Scheduling section - AWS ParallelCluster

クラスター名確認

クラスター名の一覧を出力しました。v380の名前で作成されている既存のクラスターの設定を変更します。

# pcluster list-clusters | jq -r '.clusters[] | [.clusterName,.version,.region] | @tsv'
v380    3.8.0   ap-northeast-1

環境変数に登録

確認したクラスター名と、クラスターのコンフィグファイル名を環境変数に入れます。

# set CLUSTER_NAME v380
# set CONFIG_NAME v380released.yaml

コンピュートフリートの停止

停止コマンドを実行して約 40 秒後にコンピュートフリートはSTOPPEDの状態になりました。

# pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status STOP_REQUESTED
    while true
        pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
        sleep 3
    end
{
  "status": "STOP_REQUESTED",
  "lastStatusUpdatedTime": "2024-02-11T03:13:53.844Z"
}
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOP_REQUESTED
STOPPING
STOPPING
STOPPED
STOPPED

ドライラン実行

クラスターのコンフィグチェックのために一度ドライランを実行します。Request would have succeeded, but DryRun flag is set.確認できれば基本問題ありません。

バリデーションのメッセージでマルチ AZ 起動時は AZ 跨ぎのデータ転送料に留意しなさいとご丁寧に教えてくれました。また、設定変更箇所であるqueue1のMaxCount数の変更前と、変更後の値が表示されています。

# pcluster update-cluster --cluster-name $CLUSTER_NAME \
                          --cluster-configuration $CONFIG_NAME \
                          --dryrun true

{
  "validationMessages": [
    {
      "level": "INFO",
      "type": "MultiAzRootVolumeValidator",
      "message": "Your configuration for Queues 'queue1, test1' includes multiple subnets different from where HeadNode is located. Accessing a shared storage from different AZs can lead to increased storage network latency and inter-AZ data transfer costs."
    }
  ],
  "message": "Request would have succeeded, but DryRun flag is set.",
  "changeSet": [
    {
      "parameter": "Scheduling.SlurmQueues[queue1].ComputeResources[queue1].MaxCount",
      "requestedValue": 50,
      "currentValue": 20
    }
  ]
}`

既存クラスターへコンフィグを反映

クラスターのコンフィグを既存クラスターへ反映させます。アップデートコマンドを実行して約 50 秒後にクラスターの CloudFormation スタックはUPDATE_COMPLETEの状態になりました。

# pcluster update-cluster --cluster-name $CLUSTER_NAME \
                          --cluster-configuration $CONFIG_NAME
    while true
        pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .clusterStatus
        sleep 3
    end

{
  "cluster": {
    "clusterName": "v380",
    "cloudformationStackStatus": "UPDATE_IN_PROGRESS",
    "cloudformationStackArn": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/v380/eaecf760-a463-11ee-bfc6-06ad6f88204d",
    "region": "ap-northeast-1",
    "version": "3.8.0",
    "clusterStatus": "UPDATE_IN_PROGRESS",
    "scheduler": {
      "type": "slurm"
    }
  },
  "validationMessages": [
    {
      "level": "INFO",
      "type": "MultiAzRootVolumeValidator",
      "message": "Your configuration for Queues 'queue1, test1' includes multiple subnets different from where HeadNode is located. Accessing a shared storage from different AZs can lead to increased storage network latency and inter-AZ data transfer costs."
    }
  ],
  "changeSet": [
    {
      "parameter": "Scheduling.SlurmQueues[queue1].ComputeResources[queue1].MaxCount",
      "requestedValue": 50,
      "currentValue": 20
    }
  ]
}
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_IN_PROGRESS
UPDATE_COMPLETE
UPDATE_COMPLETE

コンピュートフリートの開始（再開）

開始コマンドを実行して約 15 秒後にコンピュートフリートはRUNNINGの状態になりました。

# pcluster update-compute-fleet --cluster-name $CLUSTER_NAME --status START_REQUESTED
    while true
        pcluster describe-cluster --cluster-name $CLUSTER_NAME | jq -r .computeFleetStatus
        sleep 3
    end
{
  "status": "START_REQUESTED",
  "lastStatusUpdatedTime": "2024-02-11T03:24:44.683Z"
}
START_REQUESTED
START_REQUESTED
STARTING
STARTING
RUNNING
RUNNING

変更変更箇所の確認

ヘッドノードにログインしてパーティションの設定を確認しました。

設定を変更前に確認したパーティションの様子です。queue1は 20 ノードまでと表示されています。

# Before
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test1*    inact   infinite     10  idle~ test1-dy-test1-[1-10]
queue1    inact   infinite     20  idle~ queue1-dy-queue1-[1-20]

設定変更後に確認したパーティションの様子です。50 ノードと表示されています。

# After
$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
test1*       up   infinite     10  idle~ test1-dy-test1-[1-10]
queue1       up   infinite     50  idle~ queue1-dy-queue1-[1-50]

queue1パーティションの最大起動台数の変更に成功しました。

おわりに

最近クラスターの設定変更する機会が多く、fish ユーザーの身としては以前作成した手順が使いづらかったこともあり、fish 向けに書き直しました。以前作成した bash での変更手順の方をお客様へ案内する機会は多いと思うのですが、fish 使ってるお客様がいたら同様にプログを案内して済む様に作成しました。

また、実際に私が運用していると--dryrun trueのオプションを頻繁に--dry-run trueと誤った書き方してエラーになることが多かったのでドライランコマンドも手順に盛り込みました。多少改善が図られています。

参考

Share this article

facebook logohatena logotwitter logo

関連記事

AWS PCS入門 最小構成の PCS クラスターで共有ストレージは存在するのか確認してみた

AWS PCS入門 最小構成の PCS クラスターで共有ストレージは存在するのか確認してみた

User avatar
大村 保貴
2024.11.11
AWS ParallelCluster 環境で学ぶ Enroot の基本操作とPyxis 活用方法

AWS ParallelCluster 環境で学ぶ Enroot の基本操作とPyxis 活用方法

User avatar
大村 保貴
2024.10.14
AWS ParallelCluster 3.11.0 でコンテナベースのワークロード実行が標準サポートされました

AWS ParallelCluster 3.11.0 でコンテナベースのワークロード実行が標準サポートされました

User avatar
大村 保貴
2024.10.05
AWS ParallelCluster Slurm アカウンティング設定に必要なリソースを AWS CDK で作成してみた

AWS ParallelCluster Slurm アカウンティング設定に必要なリソースを AWS CDK で作成してみた

User avatar
大村 保貴
2024.09.25
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.